A12: Required Named Parameters Strike Back!
John Siracusa
impassioned, but ultimately futile plea for required named parameters--that
is, required arguments to a function that must be supplied as "pairs" rather
than positionally.
Here's a post from the middle of that old thread:
http://www.nntp.perl.org/group/perl.perl6.language/14689
Okay, so no one seemed to buy my argument the last time around, but now I'm
reading A12 and I see things like this:
http://www.perl.com/pub/a/2004/04/16/a12.html?page=7#the_default_constructor
> The arguments for the default constructor are always named arguments, hence
> the *%_ declaration to collect all those pairs and pass them on to bless.
http://www.perl.com/pub/a/2004/04/16/a12.html?page=9#multi_submethod_build
> It is not likely that Perl 6.0.0 will support multiple dispatch on named
> arguments, but only on positional arguments. Since all the extra arguments to
> a BUILD routine come in as named arguments, you probably can't usefully multi
> a BUILD (yet).
These passages may not seem directly relevant to my earlier argument, but I
think they do add something to the topic.
The first one confuses me a bit. The default constructor has a *%_
signature, which means it slurps up all the named parameters. It's obvious
that the default constructor is only interested in named params, but the
signature doesn't really enforce this, AFAICT. If I call a default
constructor like this:
$dog = Dog.new(name => 'Fido', age => 7, 2, 'Brown', Collar.new());
then Perl 6 won't say boo at either compile time or runtime. Or maybe I'm
wrong, but either way this isn't really an argument for required named
params since there are no required args to the default constructor anyway.
But I'm getting there (I hope), so bear with me :)
I'm not sure what the above would do, assuming the default new() doesn't
have a *@foo term waiting at end of its signature to slurp up the args 7,
'Brown', and Collar.new(). Would those args just be ignored? And what if
it was called like this?
$dog = Dog.new(2, name => 'Fido', age => 7, 'Brown', Collar.new());
Is that a compile-time or runtime error? Hm. Anyway, let's move on.
Let's supposed that I don't like the default constructor and want to replace
it with one of my own. I decode that an object of my Dog class cannot be
instantiated without a name, age, and id. But being a good Perl 6 citizen,
I document the usage of my constructor like this:
$dog = Dog.new(name => 'Fido', age => 7, id => 2);
After all, according to A12, "arguments for the default constructor are
always named arguments", so I'm trying to follow suit. I don't want my
customized constructor to be needlessly different than the default
constructor. Unfortunately, the signature for my constructor has to be:
method new($name, $age, $id, *%rest) { ... }
which means that, regardless of how I document the API, someone can do this:
$dog = Dog.new('Fido', 2, 7);
and there's nothing I can do to stop them.
...so, did you catch the fact that the second example is a two year-old dog
instead of a seven year-old dog? Maybe, maybe not, which is part of why I,
as the API designer, decided that those params should named.
Even more importantly, I decided to use named params because there's no
"natural" or implied order for the name, age, and id attributes. It's
completely arbitrary.
Okay, so it's arbitrary. Then why can't I just maintain that arbitrary
order forever and ever? In fact, if I do nothing, it will be maintained.
So what's the problem?
Yes, the answer is that "it's the principle." Name, age, and id are
required, but there is no implied order. I want them to be named params. I
am the API designer. I think it will reduce errors and make code that uses
my Dog object easier to read and maintain.
It's not as if I'm forbidding Dog users from using the indirect object
syntax or something like that. My demands are modest, useful, and
certainly no more onerous or "B&D"-esque than choosing method names or
deciding which arguments are required or any of the other things that an API
designer does.
Obviously the Perl 6 Language Design Illuminati have at least a few thoughts
in a similar direction. "The arguments for the default constructor are
always named arguments" because constructors often initialize lots of
attributes, and those attributes rarely have a natural or implied order.
Constructors just plain look and work better with named params. (The only
possible exception is a special-case for a single argument.)
But, ha ha, that's too bad if you also decide that some of the constructor
params are required! Even if nothing has changed about the lack of a
natural or implied order of the arguments, you, as the API designer, are
forced to both *choose* and *maintain forever* an arbitrary order for your
params!
I think this is a bad thing.
This may seem like it has turned into just a repeat of the Synopsis 6
discussion, but I wanted to point out that A12 has several examples of
situations where named params are the best, most natural fit. I don't think
any of those situations are intrinsically limited to also being concerned
only with optional params.
I know we are running out of special characters, but I really, really think
that required named parameters are a natural fit for many common APIs. A12
has reinforced that belief. Save me, Dami-Wan Wallnobi, you're my only
hope...
-John
Larry Wall
: I know we are running out of special characters, but I really, really think
: that required named parameters are a natural fit for many common APIs. A12
: has reinforced that belief. Save me, Dami-Wan Wallnobi, you're my only
: hope...
Well, actually, we saved you last summer when we decided to make +
mean that the parameter must be named.
Larry
Dan Sugalski
>I know we are running out of special characters, but I really, really think
>that required named parameters are a natural fit for many common APIs.
Well... maybe, but ponder a likely common case--automatically
redelegated initialization methods with classes that have parents
written in languages without named parameters. (Like, say, all the
rest...)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
John Siracusa
...named and required, or named and optional? IOW, is this all true?
sub foo(+$a, +$b) { ... }
foo(); # compile-time error!
foo(1, 2); # compile-time error!
foo(a => 1, 2); # compile-time error!
foo(a => 1); # compile-time error!
foo(a => 5, b => 7); # ok
foo(b => 1, a => 2); # ok
-John
Jonathan Scott Duff
> On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
> : that required named parameters are a natural fit for many common APIs. A12
> : has reinforced that belief. Save me, Dami-Wan Wallnobi, you're my only
> : hope...
>
> mean that the parameter must be named.
Except that last time I read, named parameters are always optional. So,
if John wants perl to carp when any of the name, age, or id is
unspecified, he's back to manually checking the parameters at run-time.
Maybe that's a feature.
-Scott
--
Jonathan Scott Duff
du...@pobox.com
John Siracusa
> At 1:14 PM -0400 4/19/04, John Siracusa wrote:
>> I know we are running out of special characters, but I really, really think
>> that required named parameters are a natural fit for many common APIs.
>
> Well... maybe, but ponder a likely common case--automatically
> redelegated initialization methods with classes that have parents
> written in languages without named parameters. (Like, say, all the
> rest...)
Then either make the order part of the API ("Sorry, we're using a C lib!")
or provide "manual" delegation with an arg-ordering wrapper. Calling out to
lesser languages is always bound to be crufty... ;)
-John
Dan Sugalski
Um. Yeah. I think it's safe to say you're going to have positional
args in core APIs for an awfully long time to come.
Larry Wall
Well, no, we're still stuck at run-time validation of that. In the case
of methods you can't really do anything else anyway, generally speaking.
For subs, we could make the compiler pay attention to something in the
declaration:
sub foo(+$a is req, +$b is req) { ... }
sub foo(+$a = fail, +$b = fail) { ... }
But I still don't think it rates a strange character of its own.
Possibly there's something going on with multi subs and invocants.
I'm not sure what 6.0.0 will make of a declaration like:
multi sub foo(+$a, +$b: +$c) { ... }
since we've told the Parrot people they don't have to worry about
anything but positional parameters for 6.0.0.
But none of this has much bearing on BUILD routines, which are shielded
from positional semantics anyway by the fact that .bless() doesn't
take any extra positional parameters.
Larry
Damian Conway
>>Well, actually, we saved you last summer when we decided to make +
>>mean that the parameter must be named.
>
> ...named and required, or named and optional?
Named and optional, by default.
> IOW, is this all true?
>
> sub foo(+$a, +$b) { ... }
>
> foo(); # compile-time error!
No.
> foo(1, 2); # compile-time error!
Yes.
> foo(a => 1, 2); # compile-time error!
Yes.
> foo(a => 1); # compile-time error!
No.
> foo(a => 5, b => 7); # ok
> foo(b => 1, a => 2); # ok
Yes. Yes.
You want:
sub foo(+$a is required, +$b is required) { ... }
Damian
John Siracusa
> On Mon, Apr 19, 2004 at 01:44:53PM -0400, John Siracusa wrote:
> : ...named and required, or named and optional? IOW, is this all true?
> :
> : sub foo(+$a, +$b) { ... }
> :
> : foo(); # compile-time error!
> : foo(1, 2); # compile-time error!
> : foo(a => 1, 2); # compile-time error!
> : foo(a => 1); # compile-time error!
> :
> : foo(a => 5, b => 7); # ok
> : foo(b => 1, a => 2); # ok
>
> Well, no, we're still stuck at run-time validation of that. In the case
> of methods you can't really do anything else anyway, generally speaking.
Why is that?
> For subs, we could make the compiler pay attention to something in the
> declaration:
>
> sub foo(+$a is req, +$b is req) { ... }
> sub foo(+$a = fail, +$b = fail) { ... }
>
> But I still don't think it rates a strange character of its own.
I'd even be willing to type out "is required." I just want the feature :)
The "is fail" technique looks slightly icky...
> Possibly there's something going on with multi subs and invocants.
> I'm not sure what 6.0.0 will make of a declaration like:
>
> multi sub foo(+$a, +$b: +$c) { ... }
>
> since we've told the Parrot people they don't have to worry about
> anything but positional parameters for 6.0.0.
Can we do some magic behind the scenes that will make "required named
params" look positional to parrot?
-John
John Siracusa
> You want:
>
> sub foo(+$a is required, +$b is required) { ... }
Yes, that would be just fine :)
-John
Dan Sugalski
>On 4/19/04 7:16 PM, Larry Wall wrote:
> > Well, no, we're still stuck at run-time validation of that. In the case
>> of methods you can't really do anything else anyway, generally speaking.
>
>Why is that?
Because at compile time all you have is a generic thing, a (possibly
indirectly accessed) method name, and a list of parameters. There's
no good way to tell which method will ultimately be called, and
validating against all declared methods of that name won't get you
anything useful there since the result's likely going to be pretty
contradictory.
> > since we've told the Parrot people they don't have to worry about
>> anything but positional parameters for 6.0.0.
>
>Can we do some magic behind the scenes that will make "required named
>params" look positional to parrot?
Maybe. There are issues of indirect named parameters (where you pass
in a scalar ref to a pair, which if I've read properly should be
treated as a named parameter) though we could have the compiler shift
'em all to the end.
The problem there is that positional parameters have to maintain
their position of the destination sub has no names--we can't go
reordering things for subs that do the traditional:
sub foo {
my ($bar, $baz, $plugh) = @_;
}
in that case the positional parameters need to stay where they are.
They also can't move if the destination sub or method doesn't do
named parameters (because either it doesn't or it's not perl 6) since
in that case the named parameters need to degrade nicely (and in
place) to their values.
John Siracusa
> At 9:50 AM -0400 4/20/04, John Siracusa wrote:
>> On 4/19/04 7:16 PM, Larry Wall wrote:
>>> Well, no, we're still stuck at run-time validation of that. In the case
>>> of methods you can't really do anything else anyway, generally speaking.
>>
>> Why is that?
>
> Because at compile time all you have is a generic thing, a (possibly
> indirectly accessed) method name, and a list of parameters. There's
> no good way to tell which method will ultimately be called, and
> validating against all declared methods of that name won't get you
> anything useful there since the result's likely going to be pretty
> contradictory.
Hm, so how would the "is required" trait that Damian posted work? Would it
simply be shorthand for a run-time check that I don't have to write myself?
I was under the impression that it would work the way I described earlier:
sub foo(+$a is required, +$b is required) { ... }
foo(); # compile-time error!
foo(1, 2); # compile-time error!
foo(a => 1, 2); # compile-time error!
foo(a => 1); # compile-time error!
foo(a => 5, b => 7); # ok
foo(b => 1, a => 2); # ok
It really is a shame about the inability to do it at compile-time with
methods, but shorthand for a run-time check in that case would be welcome
too :)
-John
Dan Sugalski
>On 4/20/04 10:42 AM, Dan Sugalski wrote:
>> At 9:50 AM -0400 4/20/04, John Siracusa wrote:
>>> On 4/19/04 7:16 PM, Larry Wall wrote:
>>>> Well, no, we're still stuck at run-time validation of that. In the case
>>>> of methods you can't really do anything else anyway, generally speaking.
>>>
>>> Why is that?
>>
>> Because at compile time all you have is a generic thing, a (possibly
>> indirectly accessed) method name, and a list of parameters. There's
>> no good way to tell which method will ultimately be called, and
>> validating against all declared methods of that name won't get you
>> anything useful there since the result's likely going to be pretty
>> contradictory.
>
>Hm, so how would the "is required" trait that Damian posted work? Would it
>simply be shorthand for a run-time check that I don't have to write myself?
Yes. It may have the added advantage of continuing the search for a
sub that matches--that is, we could continue on as if we'd not found
the sub and then hit MMD. Or not. I could see it going either way.
>It really is a shame about the inability to do it at compile-time with
>methods, but shorthand for a run-time check in that case would be welcome
>too :)
Everybody's OO gets hit this way, unless you get really vicious with
the signatures of overridden methods. (If they're all the same it's
easier) Perl's really dynamic nature makes it tough for subs, too.
Aaron Sherman
> Hm, so how would the "is required" trait that Damian posted work? Would it
> simply be shorthand for a run-time check that I don't have to write myself?
> I was under the impression that it would work the way I described earlier:
>
> sub foo(+$a is required, +$b is required) { ... }
Your example is a non-multi sub, which AFAIK means that you can do this
at compile time. But for multis and methods, I think Larry and Dan's
comments still hold.
The likelyhood that P6.0.0 will make this distinction is another thing.
I'd rather have a language that works than one that is complete. Plenty
of time to complete it later, but those who are thinking of taking on
large-scale development with it (e.g. converting over large CPAN modules
or implementing new Perl6ish libraries) just want something that runs :)
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
John Siracusa
> On Tue, 2004-04-20 at 10:51, John Siracusa wrote:
>> Hm, so how would the "is required" trait that Damian posted work? Would it
>> simply be shorthand for a run-time check that I don't have to write myself?
>> I was under the impression that it would work the way I described earlier:
>>
>> sub foo(+$a is required, +$b is required) { ... }
>
> Your example is a non-multi sub, which AFAIK means that you can do this
> at compile time. But for multis and methods, I think Larry and Dan's
> comments still hold.
>
> The likelyhood that P6.0.0 will make this distinction is another thing.
> I'd rather have a language that works than one that is complete. Plenty
> of time to complete it later, but those who are thinking of taking on
> large-scale development with it (e.g. converting over large CPAN modules
> or implementing new Perl6ish libraries) just want something that runs :)
Yes, it appears that runtime checks for the existence of required params
will continue to be a necessary part of Perl programming. I suppose a
saving grace is that Perl 6 will support "real" assertions that disappear
entirely from the program flow when a switch is flipped.
-John
John Siracusa
> Yes, it appears that runtime checks for the existence of required params
> will continue to be a necessary part of Perl programming.
...of course, there are at least two ways to do "runtime checks":
* runtime checks that the programmer has to write himself
* runtime checks that the compiler generates automatically
(presumably using a trait like "is required")
I'm sure someone will write the latter if it's not part of the core
language...hint hint :)
-John
Dov Wasserman
Back on the topic of required named parameters, I think John Siracusa's
initial post did a good job of separating the two concepts of parameter
mandate (required vs. optional) and parameter designation (by position vs.
by name). Each of these dimensions can be very useful, and IMHO should be
independently supported by the language.
An earlier A6 issue which I wasn't crazy about (once John's post got me
thinking about it) is that the parameter zone marker '+' on +$foo denotes
two different things:
1. parameter $foo must be passed by name only (and not by position)
2. parameter $foo is optional
I imagine we all agree that most named-only parameters will be declared to
be optional in practice. That is likely why Larry designed the '+' marker to
declare both meanings. We also now seem to have consensus that required
named parameters should somehow be supported by the language; at
compile-time when possible (subs), or at run-time when not
([multi-]methods). However, I don't think the single '+' character should
denote both meanings.
What we are really trying to say with a "named-only" parameter is that this
parameter has no numeric positional place; it only has a name. The '+'
symbol to me implies something which is required. In Perl 6, it generally
coerces its unary operand to a numeric context. Given that the '+' zone
marker in A6 means "this parameter is optional and it is has no numeric
position", this visual marker is either highly misleading, nonsensical, or
both.
Since in the rest of Perl 6, the '~' operator involves string
representation, perhaps the standard +$foo marker should really be ~$foo:
i.e., $foo only has a (string) name, not a numeric position. Thus ~$foo
would mean exactly what +$foo currently means: $foo may only be passed by
name, and it is optional.
Declaring a parameter to be named-only would now require a different syntax.
For your parametric perusal pleasure:
1. sub foo($req1, ?$opt1, ~$optNamedOnly, ~$reqNamedOnly is req) {...};
2. sub foo($req1, ?$opt1, ~$optNamedOnly, +$reqNamedOnly) {...};
3. sub foo($req1, ?$opt1, ~?$optNamedOnly, ~$reqNamedOnly) {...};
4. sub foo($req1, ?$opt1, $optNamedOnly is named, $reqNamedOnly is named
is req) {...};
Version 1 simply replaces '+' with '~' for psychological/visual purposes,
and keeps all named-only parameters as optional, unless declared otherwise
by the "is req" trait. It has the advantage of being closest to the current
spec. It has the disadvantage of silently switching the parameter mandate
default from required to optional when you declare a parameter's designation
as named-only. You can override the mandate with "is req", but this is
inconsistent with "$req1" being already required by default.
Version 2 uses '~' for "optional named only parameter", and transforms '+'
to mean "required named-only parameter". It has the advantage of keeping all
zone markers to 1 character without additional traits. It has the
disadvantage of using '~' and '+' to mean two things that are somewhat
similar and somewhat different.
Version 3 uses '~' for all named-only parameters, which by default are
required (like positional parameters). You must insert a '?' to make the
parameter optional. There is no '+' zone marker (at least for these
purposes). This version has the advantage of using the same '?' token for
the same purpose as the other marker(s). I also think it is a visual
advantage to have all named-only params declared with the same marker, '~'
in this syntactic version. It has the disadvantage of needing 2 chars '~?'
(or '?~', but IMHO not either) to declare the common case of "optional
named-only", and only 1 char for the less common "required named-only". This
is poor Huffman coding. However, I remain confident that Larry can devise a
better Huffman-coded scheme than I have which still addresses the main
points. ;-)
Version 4 basically throw its hands up and decides that the semantics we
want are too complex to denote in a single character. It is simple, but
verbose. Probably the various '~/?/+' markers translate into similar
'named/optional/required' traits that we can always declare explicitly if we
want to.
OK, I just wanted to throw some ideas in the air. Whether they end up being
required reading or unnecessary needling is up to you. I will not take a
position on the matter.
-Dov Wasserman
d...@wass.ws
"Larry Wall" <la...@wall.org> wrote in message
news:20040419231...@wall.org...
Luke Palmer
> Long-time lurker, first time poster. Dittos, kudos, etc.
Welcome aboard.
> Since in the rest of Perl 6, the '~' operator involves string
> representation, perhaps the standard +$foo marker should really be ~$foo:
> i.e., $foo only has a (string) name, not a numeric position. Thus ~$foo
> would mean exactly what +$foo currently means: $foo may only be passed by
> name, and it is optional.
Hmm... I'm quite sure that I like ~ better than + for mnemonic purposes.
> Declaring a parameter to be named-only would now require a different syntax.
> For your parametric perusal pleasure:
>
> 1. sub foo($req1, ?$opt1, ~$optNamedOnly, ~$reqNamedOnly is req) {...};
> 2. sub foo($req1, ?$opt1, ~$optNamedOnly, +$reqNamedOnly) {...};
> 3. sub foo($req1, ?$opt1, ~?$optNamedOnly, ~$reqNamedOnly) {...};
> 4. sub foo($req1, ?$opt1, $optNamedOnly is named, $reqNamedOnly is named
> is req) {...};
I'm for option 1.
The reason I don't think that named-only and required should get huffman
privilidges is simply because of the rarity of use. We've had arguments
that they'll be used often, but I don't think they will. The main
argument is: what if I want to add a required parameter but not break
compatibility. Well, if you've added a required parameter, you've just
broken compatibility, named or not.
Although I can see wanting a fully documentary interface, that's really
the caller's decision. Perl enjoys leaving the decisions to the caller:
thus C<use fatal>. It's a philosophy that I strongly agree with.
A newer point that was brought up is that with the new implicit *%_ on
methods, required named parameters seem more viable. But the reason the
implicit *%_ was introduced is so that derived methods could add
parameters without violating the Liskov substitution principle. Adding
a required named parameter would do just that.
On the other hand, Perl's always been a purist in impurity. There are
more subtle reasons for wanting to add a required named parameter.
Adding the => syntax to a method call, while the parameter isn't
formally named, can be a useful language building idiom. That's why I
support the C<is req[uired]?> trait. But making a special character
sequence for it will end up confusing people, being mishuffmanized.
Luke
Jonathan Scott Duff
> Dov Wasserman writes:
> > Since in the rest of Perl 6, the '~' operator involves string
> > representation, perhaps the standard +$foo marker should really be ~$foo:
> > i.e., $foo only has a (string) name, not a numeric position. Thus ~$foo
> > would mean exactly what +$foo currently means: $foo may only be passed by
> > name, and it is optional.
>
> Hmm... I'm quite sure that I like ~ better than + for mnemonic purposes.
I agree.
> > Declaring a parameter to be named-only would now require a different syntax.
> > For your parametric perusal pleasure:
> >
> > 1. sub foo($req1, ?$opt1, ~$optNamedOnly, ~$reqNamedOnly is req) {...};
> > 2. sub foo($req1, ?$opt1, ~$optNamedOnly, +$reqNamedOnly) {...};
> > 3. sub foo($req1, ?$opt1, ~?$optNamedOnly, ~$reqNamedOnly) {...};
> > 4. sub foo($req1, ?$opt1, $optNamedOnly is named, $reqNamedOnly is named
> > is req) {...};
>
> I'm for option 1.
[ well-reasoned ... um ... reasons elided ]
> On the other hand, Perl's always been a purist in impurity. There are
> more subtle reasons for wanting to add a required named parameter.
> Adding the => syntax to a method call, while the parameter isn't
> formally named, can be a useful language building idiom. That's why I
> support the C<is req[uired]?> trait. But making a special character
> sequence for it will end up confusing people, being mishuffmanized.
I agree here too.
Larry Wall
: > Hmm... I'm quite sure that I like ~ better than + for mnemonic purposes.
:
: I agree.
I think + is easier to see. Mnemonic value is a secondary issue in
something that will be used so heavily.
Larry
Austin Hastings
Doubtful. Everytime I see a P6 signature, I'm shocked by the cruft that's
accumulated at the front of the varname. I 'see' the space, regardless of
what's there.
In this case, the reliance on saying:
if (+$x > 9) ...
to disambiguate logical/arithmetic/string/whatever context in expressions is
going to sit at cross purposes to the +-as-required-arg usage. It'll be yet
another source of learning curve gradient to no real purpose.
method x ($me: $req, ?$opt, +$namedopt, *%named, *@list) {...}
vs:
method x($me: $req, ?$opt, ~$namedopt, *%named, *@list) {...}
=Austin
Larry Wall
: In this case, the reliance on saying:
:
: if (+$x > 9) ...
:
: to disambiguate logical/arithmetic/string/whatever context in expressions is
: going to sit at cross purposes to the +-as-required-arg usage. It'll be yet
: another source of learning curve gradient to no real purpose.
:
: method x ($me: $req, ?$opt, +$namedopt, *%named, *@list) {...}
: vs:
: method x($me: $req, ?$opt, ~$namedopt, *%named, *@list) {...}
Using ~ is not an improvement in that respect. Named arguments are
not in string context.
Larry
Dan Sugalski
Looking at this, all I can think is "I hope there's a long-form of
all this punctuation notation for those of us old and feeble folks".
Austin Hastings
> : In this case, the reliance on saying:
> :
> : if (+$x > 9) ...
> :
> : to disambiguate logical/arithmetic/string/whatever context in
> expressions is
> : going to sit at cross purposes to the +-as-required-arg usage.
> It'll be yet
> : another source of learning curve gradient to no real purpose.
> :
> : method x ($me: $req, ?$opt, +$namedopt, *%named, *@list) {...}
> : vs:
> : method x($me: $req, ?$opt, ~$namedopt, *%named, *@list) {...}
>
> Using ~ is not an improvement in that respect. Named arguments are
> not in string context.
True. I hear that backtick is available. ;-) My point, though,
was that both are about the same, visually.
I could at least see the "string" -> "has a name" association.
In this case, though, perhaps an explicit reference to the
regex-meaning, as opposed to the contex-meaning, will get the
point across.
To answer Dan's posting: I fully expect to never use any of these
sigils, myself. I'm sure there will be traits for this- nice
verbose traits. (Signatures are about as write-once as you can get...)
method x(
requires:invocant $me,
requires $requisite,
$mandatory,
$necessary,
optional $maybe,
$possible,
$potential,
$unlikely,
named $yclept,
$hight,
$aka,
named:* %named,
va_list @list)
{...}
=Austin
John Siracusa
> To answer Dan's posting: I fully expect to never use any of these
> sigils, myself. I'm sure there will be traits for this- nice
> verbose traits. (Signatures are about as write-once as you can get...)
>
> method x(
> requires:invocant $me,
> requires $requisite,
> $mandatory,
> $necessary,
> optional $maybe,
> $possible,
> $potential,
> $unlikely,
> named $yclept,
> $hight,
> $aka,
> named:* %named,
> va_list @list)
> {...}
What happened to my poor "required, named"? Oh, the pain!
method foo (+$bar is required) { ... }
method foo (~$bar is required) { ... }
Eh, I've never been a fan of ~ (even for concatenation...sigh, dot has
ruined me forever). Anyway, once we're spelling things out, don't forget to
throw in some traits for params that are required and must be provided as
pairs. Damian promised! ;)
-John
Abhijit A. Mahabal
On Wed, 5 May 2004, John Siracusa wrote:
> Anyway, once we're spelling things out, don't forget to throw in some
> traits for params that are required and must be provided as pairs.
> Damian promised! ;)
Looking thru what exists of P6C I saw this in P6C/Nodes.pm:
use Class::Struct P6C::signature => { qw(positional @
optional @
required_named @
slurpy_array $
slurpy_named $
optional_named @
) };
So in theory it is all there :), and must have been for a while! It does
not (yet) have an invocant, but the required_named is there.
> -John
--Abhijit